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Description 

Technical Field 

This invention relates to computer system interfac- 
ing, and, more particularly, relates to support for the in- 
terfacing of applications written in a plurality of languag- 
es to a software system, 



Background Art 

First an overview of the problem solved by the in- 
vention will be given followed by a more detailed discus- 
sion of the problem and attempted solutions of the prior 
art. In computer systems it is often desirable to support 
interfacing of applications written in a plurality o1 com- 
puter languages to functions of a software system such 
as a database manager of the OS/2™ operating system 
of the IBM Corporation. However, different computer 
languages have different interface requirements which 
means, for example, when a program written in a given 
language calls another program written in a different lan- 
guage, the latter is expected to preserve the contents of 
certain registers in the processor of the computer sys- 
tem. On the other hand, however, the program being 
called or "callee" such as a database manager function 
expects the caller to pass parameter information in a 
predefined pattern. Examples of such requirements are 
that (1) some parameters are expected to be a value to 
be used whereas other parameters are expected to be 
the address of where the value is; (2) parameters such 
as an array of byles may be expected to be null termi- 
nated, i.e., to have a last byte of 0; and (3) the order of 
parameters that are such values and/or addresses may 
be expected by the caliee to be passed by the caller in ; 
a specific predefined pattern or order such as values 
first, or intermixed in a set order. 

Because computer languages vary as to such re- 
quirements as those hereinbefore illustrated, the prob- 
lem in supporting interfacing of applications written in 4 
different languages conventionally would have to be 
solved by providing separale interfaces to the database 
manager or other function set for each language to be 
supported. Alternatively a new entry point must be de- 
signed for each function which could accept parameters * 
in a way acceptable to most computer languages and 
which would set up a call to the existing. entry point, both 
alternatives having obvious drawbacks in terms of re- 
quired development effort, maintenance, and the like 

Thus, in summary any time the need arises for one sc 
piece of software to interface and access with another 
(which may include a single kernel ol programming serv- 
ices such as a database, an operating system, or even 
the basic inpul-oufput service or "BIOS"), this need for 
a convention arises of how to communicate, i.e., how to ss 
pass parameters, return results or codes or the like con- 
sistently. Conventions are established and predefined 
by each particular programming language each of which 



has different interface specifications. When both the 
caller and callee are written in the same programming 
language because Ihespecificationsare identical for the 
caller and callee applications written in a single lan- 
guage such as FORTRAN or the like interfacing is not 
problematical inasmuch as these interface require- 
ments are handled by the language. Thus the compiler 
attends lo what must be done to pass and return infor- 
mation such as parameters which need lo be passed to 
» !he caller, results such as data which must be returned 
and the like. In a typical database example this data and 
parameters might include the name of a database lo be 
creafed which is passed lo the caflee which creates the 
database, and a result code, i.e., whether or not the da- 
>s tabase was created, which must be returned to the call- 
More detailed examples of these conventions wh ich 
establish precise manners in which applications must 
communicate follow. In a database kernel for example 
** written in the C-Language assumptions are made that 
callers must pass names to the kernel for access with a 
null byte at the end so the kernel recognizes the length 
or end of the name. Thus, the database continuously 
made assumptions, for the example regarding names 
coming from anywhere and even internally such as an 
assumption thai a siring character would always be null 
terminated. As an illustration of why this was always a 
concern, when calling runtime libraries a function would 
be called without lha length of string passed which must 
o have a null terminator and if this was not present the 
desired function typically could not execute property. 
Such required convenfion implied thai the caflr-r also 
had to be written in the C-Language so that any time a 
name character string was passed the compiler would 
5 consistently add a null automatically so that when the 
string was passed to the keme! it was recognized as a 
string. Another language such as FORTRAN might have 
a different convention for terminating a string whereup- 
on an application written in FORTRAN would not have 
such a null terminator. However, because the database 
kernel expects the missing null lerminator, the program 
would not execute correctly 

string termination is only but one specific example 
of problems associated with requirements of different 
languages in successful interfacing. Yet another typical 
different problem interfacing applications written in dif- 
ferent languages related to the passing of values and' 
or addresses. This was typically the most troublesome 
inasmuch as languages might only pass one or the other 
or require that they be passed in a certain predeter- 
mined order. Thus "call by reference" or "call by value" 
requirements were another point of inconsistency pre- 
venting applications written in different programming 
languages from effecting successful calls. As a specific 
example illustrating problems associated with ordering 
and parameter type requirements, COBOL required that 
ail parameters by value be passed first followed by all 
parameters of reference with no cominglino, whereas 
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FORTRAN onjy passed by reference. 

A generic remote procedure call facility is described 
in "Facilitating Mixed Language Programming in Distrib- 
uted Systems" by R Hayes and R D SchliChting, in IEEE 
Transactions on Software Engineering, vol SE-13. No 
12, December 1987, pages 1254-1264. A cross-lan- 
guage cail is supported by associating agents with the 
catling and called programs. The agents communicate 
in a predefined parameter language, and can therelore 
act as intermediaries between the calling and called pro- 
Yet problems in interfacing applications written in 
different languages were not even limited to inconsist- 
encies in the manner in which strings or value/reference 
calls were handfed by the various languages but includ- 
ed additional factors such as the amount of current state 
information of the processor which was slored when the 
callee such as the database manager assumed contra! 
after being called by a given application. Some applica- 



development effort, overall maintenance and support in- 
volved in providing external entry points to software 
products from applications written in a wide variety of 
languages having different interfacing requirements and 
specifications. 

Summary of the Invention 

The present invention is defined in the attached 

A support system and method for intertacing of 
computer application programs written in a plurality of 
languages to a software system such as a database 
manager or the like is provided. 

For each of a plurality of functions supported by the 
software, a generic application program interface or en- 
try point is defined having a plurality of parameters in a 
consistent form required by the system to execute the 
function. Parameter consistency addressed includes 



tions written in one language might expect certain con- » parameter order, null termination, manner of variable 
tents of registers to be identical upon return to the ap- 
plication and if not preserved by the database kernel for 
example prior to their being changed by the kernel the 
application would not subsequently execute properly. 



passing by value or address, and the tike. Each entry 
point may be called by an application program written 
in any of the plurality of languages and transforms the 
parameters o! the call into the consistent generic form 



This was particularly a problem with respect to multiple ss ( or execution of the software 
threaded code or multithreading wherein a portion of a 
program or thread could run asynchronously with the re- 
■ maining parts of the same or another program. When 
each program piece was running the state of the ma- 
chine would bo different and yot the same function of 
the database kernel or other software might be getting 
called by these different pieces of code. When a second 
thread called a particular application program interface 
register state information regarding a prior call of a pre- 



Tho processor state corresponding to a thread is 
stored in response to the call in a table accessible to 
and shared by ail ihe generic application program inter- 
laces but not accessible by the application programs. 
The function of the underlying software system is then 
called. Upon return from the call and execution of the 
lunction by the system, the processor state is restored, 
and return code information and control is then returned 
the application program. The approach obviates the 



vious i iread slored in memory would conventionally be 35 need tor separate entry points for applications' 



written over thereby preventing proper subsequent ex- 
ecution of Ihe programs. 

In summary then, different interface requirements 
existed for different programming languages and appli- 
cations written thereto. II a claim was to be made that a 
software product such as a database or the like could 
be accessed by applications written in more than one 
language, a way must be provided for those applications 
to calf the database successfully which satisfied the re- 
quirements of applications written to all languages sup- 
ported. Accordingly a means was long sought after lor 
effecting interfacing of applications written in a pluraiity 
of computer languages. Such a system and method was 
highly desired moreover which avoided necessity lor im- 
plementing a separate interface for each function for 
each application language to be supported. A solution 
was sought after which further avoided the need for de- 
signing a new entr y ' point for each such function which 
could accept parameters acceptable to a plurality of 



each different supported procedural language Attend- 
ant increased development effort maintenance and sup- 
port necessary for duplicate entry points for each lan- 
guage is thereby avoided by the catenation and uniform 
ordering of Ihe interface requirements of the various lan- 
guages. 

In a particular embodiment, an entry point is defined 
for each of a plurality of functions supported by a data- 
base manager such as the creation, destruction, addi- 
tion or scanning of a database. For each such new entry 
point defined to the plurality of functions which could be 
called from each application a set of parameters was 
defined per the needs of Ihe particular database func- 
tion, such parameters being unilormiy consistent to the 
database and callable from application programs written 
in a plurality of languages. One entry point of'the em- 
bodiment receives indications of string length in different 
forms resulting from different manners of specifying 
siring length associated with a plurality of different Ian- 



computer languages to set up a call to an existing entry ss gU ages and transforms such indications of string length 

point. Still further a solution providing for interlacing of into a uniform format comprehensible by the pre-e-xist- 

applicalions written in a plurality of computer languages ing singular requirements ol the database manager for 

was urgently needed which could substantially reduce string recognition. Specifically a oarameier is included 
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in the entry point indicating string length which automat- 
ically adds a null byte to designate termination of the 
string. Also in a preferred embodiment provision is made 
for multithreaded code in the system of the invention. 
When a first application program interface is cailed the 
system calls the operating system to retrieve the iden- 
tification number of the calling thread, each thread hav- 
ing a unique identification number. The buffer stores the 
entire processor slate information, and the IDs are used 
to index into the table. When a particular thread's stale 
information is saved, the information is written over 
memory space designated only for that particular 
thread. 

Brief Description of the Drawing s , 

The novef features believed to be characteristic of 
(he invention are set forth in the appended claims. The 
invention itself, however, as well as other features and 
advantages thereof, will be best understood by refer- 2 
ence to the following description of the preferred em- 
bodiment, when read in conjunction with the accompa- 
nying figures, wherein. 

Fig. 1 is a functional block diagram of the system of 
the invention. S! 

Fig. 2 is another functional block diagram of the sys- 
tem of Fig. 1 . 

Fig. 0 is a diagram of the invention illustrating inter- 
action with the system processor registers andmemory. 

Fig, 4 is a more detailed illustration of the processor 3C 
state storage feature of the present invention. 

Figs. 5-7 is a flow diagram for construction of ge- 
neric application program interfaces in the manner of the 
present invention. 

35 

Detailed De scription of the Preferred Embodimem 

Illustrated in Fig, 1 is a functional block diagram of 
the computer system of the invention which illustrates 
the problem giving rise to the need (or the invention, tn *o 
such a system an operating system 18 is typically pro- 
vided which receives system calls from a plurality of op- 
erating system application program interfaces 20. 
These system calls provide essentially the same pur- 
pose as generic APIs 14, i.e., they provide entry points is 
so that application programs 16 can access the operat- 
ing system 18 to obtain necessary services such as the 
creation of a window, reading or opening of a file, etc., 
such functions beingsimilartothevariousdiflerent func- 
tions of the applications 1 6 in accessing a program 10 so 
such as a database or the like. At this point it will be 
noted that an embodiment of the invention will be dis- 
closed herein with reference to the OS/2™ Extended 
Edition 1.0 computer program which includes an oper- 
ating system and database managerfunction. However, 
in using a specific operating system and program serv- 
ice 10 to itiustrale the invention, the intent is not to limit 
the application of the in r ,t q iner zr ~ ac _ 



ccrdingly the inventive concepts herein disclosed are 
contemplated as being readily adaptable to a wide va- 
riety o< operating systems 1 8 and programming services 
10. 

s Stilt referring to Fig, 1, it wili be recalled that one 
problem associated with prior systems was that the op- 
erating system 18 and program services 10 assumed 
Inat application 16 would be written in the same lan- 
guage and accordingly appfication program interfaces 
"> such as the APIs 20 to the operating system 18 and Ihe 
APIs to the particular program services 10 such as da- 
tabase manager APIs 12 were interfaces written to a 
specific language. Thus, the APIs 12 and 20 ware not 
generic and did not expect to be called from applications 
,s 16 written in more than one programming language 
Thus, for example, if the database manager program 
services 10 was written in the C-Language, the associ- 
ated D8M APIs 12 expecfed calls from the applications 
16 such as a call to create or delete a database to con- 
■° form to calls in the C-Language and when such calls 
from the applications 16 were in a different language, 
the applications 16 would not execute properly. In the 
present invention, however, a plurality of generic APIs 
14 are provided to these pre-existing entry points of ihe 
S DBM APIs 1 2 and operating system APIs 20 whereby 
the invention generalizes existing entries to a plurality 
of applications 16 written in any of a number of prede- 
termined languages. Thus the function of the generic 
APIs 14 of the present invention is to transform param- 
' stars received in a number of different formats deter- 
mined by the particular language in which the applica- 
tion 16 is written m!o forms expected by the DBM APIs 
1 2 and operating system APIs 20 as dictaled by Ihe par- 
ticular procedural language in which these APIs 12 and 

Before proceeding lo more detailed description of 
the invention, an additional feature depicted in Fig. 1 will 
be noted which will also be hereinafter described in 
greater detail. In accordance with modern programming 
technique, it is contemplated that application 16 may be 
of a multi-threaded variety whereby one or more such 
applications may include a plurality of threads or pieces 
of code which may run asynchronously with respect to 
all remaining parts of the same or other programs or ap- 
p.ications 16, such threads being functionally designat- 
ed by T, - T 4 . In accordance with the invention each time 
one of such threads calls an AP1 14 the state information 
of the processor in the computer executing the system 
of the invention must be saved in a particular manner in 
a state preservation table 1 7. It is a feature of ihe inven- 
fion that each thread has a unique thread ID associated 
therewith as well as a unique memory space or location 
in the table 17. The processor siate lor each thread is 
periodically stored in >!s unique corresponding localion 
in ihe table and written over prior such information cor- 
responding to the same thread in a manner to be here- 
inafter described in greater detail. 

Referencing now Fig. 2 a more detailed descript ion 
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of the workings of Ihe invention will be described. A soft- 
ware system 42 is provided which for purposes of gen- 
erality may be any system which must be accessed by 
a plurality of applications and might include an operaiin g 
system, a database function, or even basic input/output 
services or BIOS. An interface 40 is provided to the sys- 
tem 42 whereby Ihe system 24 estabfishes certain re- 
quirements such as predefined entry points 36 with in- 
terlace requirements 34 to the outside world of applica- 
tions (such as ihose of Fig. 16 of Fig. 1 ). The syslem 22 
further therefore establishes requirements of interfaces 
33 to the system 42. The interfaces 34 and 38-40 for an 
operable system are compatible inasmuch as the sys- 
tems 22 and 24 pre-exist and were written in the same 
language. It wiil be recalled that the invention general- 
izes these existing entries and thereby provides a sys- 
tem 26 with an interface 32 compatible with the interface 
requirements 34, However it is important to note with 
respect to Fig. 2 that the system 26 of the invention pro- 
vides a generic interface 28 lo these different applica- 
tions 15 written in different languages thereby providing 
a collection of generic entry points 30 to the software 
system 42. In other words, the system 26 of the inven- 
tion provides generality to an existing software system 
42. Moreover, because systems 22 and 24 pre-exist, the 
system 26 of the invention may be written as desired in 
machine code or assembly ianguage whereby the pre- 
existing interfaces may be changed in a general way 
providing generality lo existing entry points lo the soft- 
ware system 42. This is accomplished by manipulating 
the stack of the processor whereby essentially mapping 
of interfaces 28 and 32 is effected. In providing such 
mapping, the caller's return address is removed from the 
slackas will hereinafter be made clear in a more detailed 
description with reference to the How diagrams. In this 
manner, a call made to the generic entry points 30 ap- 
pears to ihe system 22 as if it was coming directly from 
the application, i.e., the stack is made to appear lo Ihe 
system 22 as if the call was originating directly from the 
application 16. One function the system 26 does to ac- 
complish this is to remove the return address from the 
stack whereby the system 22 does not see the return 
address on the stack but rather the return address from 
the system 26. In this manner mapping between the ge- 
neric interlace 28 and the interface 34 having specific 
requirement of the existing entry points 36 is made 
transparent lo the system 22. This is accomplished by 
the steps outlined with reference to the Figs. 5-7 and 
detailed description thereof which hereinafter follow. 

Referring now to Fig, 3, a database application pro- 
gram 54 written in a high level computer language is pro- 
vided for use with the system of the invention depicted 
therein. Such a program 54 may be structured as two 
or more asynchronous units or threads of execution as 
represented conceptually by thread number 1, 58 and : 
Ihread number 2, 56, Program 54 employes the services 
of a database manager software system 96. Access to 
this system 96 is through interface entry points, i.e.. 



function calls, indicated as the database interface 95. 
These entry points are suitable lor access by applica- 
tions written in the same language as the system 96 or 
in assembly language. Services provided by the system 
s 96 and accessed by application program 54 (and 
threads 56, 58} are those services commonly associat- 
ed with a database management software system such 
as Release 1 .Oof the Extended Edition of the aforemen- 
tioned OS/2™ operating system. 
10 The system 96 accesses the services of the oper- 
ating sysiem 98 through the operating system interface 
entry points 97. Services provided by the operating sys- 
tem 98 and accessed by system 96 are those services 
commonly associated with a computer's operating sys- 
>s tern, interface entry points are provided as represented 
by reference numerals 60 and 62 for access to the sys- 
lem 96 by database applications written in languages 
other than the language usedto write the database man- 
ager software and other than the assembly language of 
20 the machine employed in the computer system used to 
Implement the invention. Because threads 56 and 58 
are asynchronous in their execution, it is possible for 
Ihem to make simultaneous access calls 92 and 94, re- 
spectively, to a generic AP! such as API 62. 
25 Still referring to Fig. 3, at reference numeral 200 
there is indicated a portion of the computer's main mem- 
ory such as RAM which is reserved and shaicd by the 
generic APIs such as API 60 and 62 in order to store the 
contents of registers 50 ol the machines processor 51 . 
so The contents of the set of all the processor's registers 
50 at any given time is known as the processor's state, 
as represented generally at 52. The memory, and more •■ 
particularly a register preservation table therein, ai 200 
reserves a number of bytes sufficient for storing a 
35 number of processor states or entries in the table equal 
to the maximum number of threads allowed by the op- 
erating syslem 98 in an application . The memory portion 
200 will be hereinalter described in greater detail with 
reference to Fig 4 which follows. Reference numeral 48 
■'•o is intended to indicate a portion of the computer's main 
memory which is used as an information stack for the 
active or current execution thread. The operating sys- 
tem 98 requires a separate slack for each such execu- 
tion thread. Upon activation by a call such as call 94, the 
«5 APi reads, as indicated by the arrow 70, the state of a 
register52 of the processor51 and stores it as indicated 
by arrow 46 in the current thread's stack 48 before it 
causes the processor's state to change. API 62 makes 
calls 100 and 101 to obtain identification numbers for 
so each o) the calling threads. It will be recalled that each 
identification number is a unique number assigned by 
the operating system 98 (o a particular thread and is a 
member of a finite set also defined by the operating sys- 
tem 98. 

« Once the API 62has obtained a thread identification 
number for the call 94 it transfers, as indicated by arrows 
72 She processor's state 44 from the stack 48 io the eniry 
in :he table 200 co-responding lo me ihreac idontificw- 
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tion number for call 94 which came from the thread 58. 
The API 62 then proceeds to make the parameter f;xes 
as described in the algorithm with reference to Figs. 5-7, 
after which it makes a call 94A to the database manager 
interlace 95. API 62 is able to do this because it is written 
in assembly language and therefore can access the in- 
terface 95. Upon receiving control back from call 94A, 
the API 62 reads, as indicated by arrows 86 the entry in 
table 200 corresponding to the identification number for 
call 94 and restores, as indicated by arrow 71 , the con- 
tents of the registers 52 of the processor 51 . This step 
is done as the last step prior io returning control to the 
caller 58. 

The hereinbefore noted steps of the API 62 reading 
and storing the processor state and making the calls 1 00 ' 
and 101 to obtain the identification numbers could be 
applied to call 92 by thread 56 as well and could occur 
simultaneously to the hereinbefore noted steps as de- 
scribed with respect to call 94. Since the thread's iden- 
tilication numbers are unique, then the entries in table 2 
200 used .to store the processor's state, as in registers 
52 are also unique. This thereby insures preservation of 
the processor's state regardless of the use of multiple 
execution In reads by the applicat ion prog ram 54. A sep- 



arale generic point 60 sharing the same memory space ss API 62 can access alobal 



Fig. 5 is a flow diagram of a sodware program for 
implementing the invention. The flow is entered at block 
100 from a thread in a given application program 16 of 
Fig. 1. Before describing in detail the afgorithrn of Fig. 1 
it is helpful to provide an over view of ihe functions per- 
formed thereby. The steps of Fig. 5 illustrate the algo- 
rithm by which a generic API of the invention first re- 
ceives a csh from an application program 1 6 which uses 
a generalized interlace and preserves the state of the 
computer system's processor at the time of the call. The 
algorithm then adjusts these parameters to conform to 
the requirements of an underlying existing function writ- 
ten in a different language of the existing API. The ex- 
isting API is then called and the state of the processor 
is restored with resultant information being returned to 
tne application. The generic application 62 such as the 
first application shown therein in Fig. 3 wili store as 
shown by arrow 46 partial processor state or the current 
threads slacks 48, such state being stored as shown at 
reference numeral 44 of Fig. 3 After the processor state 
has been stored, step 1 00 ol Fig. 5, registers of the proc- 
essor are set up at 1 02 such that the API 62 can access 
the current thread's stack 48. At step 104 a similar pro- 
cedure sets up the dala segments such that the current 



of the' table 200 with API 62 can only be called by 
thread 53 after call 94 to API 62 returns execution con- 
trol to thread 58. This restriction is inherent in the way 
that the machine instructions, which comprise the code 
of an execution thread, are performed sequentially. This 
step of a separate generic entry point 60 sharing the 
same memory space 200 guarantees thai none ol the 
generic API's sharing memory represented by table 200 
will be called more than once at the same time from the 
same thread. This in turn guarantees preservation ol the 
data stored in the entries of table 200 between the time 
that the copy 72 and restore 86 are performed for any 
given call. 

Referring now to Fig. 4, a format shown generally 
and schematically by reference numeral 160 is assigned 
to a reserved portion of the computer's main memory for 
use as temporary storage for the processor 51 state in- 
formation during calls to a set of generic entry points to 



ervalion table. With respect to these set up steps 102 
and 104, the, embodiment under discussion employs 
processors using segmented addressing modes al- 
though the invention is not intended to be so limited. 
1 Each API owns a certain amount of memory in the pres- 
ervation table 80 having a base address which was al- 
located to each API through the linking process. The 
"set up" step relers to loading into a data segment cor- 
responding to each API the base address of the memory 
space in the (able 80 corresponding to such API. 

At slep 1 06 a test is performed relating to accessing 
operaling system 98 information and, more particularly 
a block of memory in which the operating system stores 



ID of the current caller or application program running.. 
This ID initially has to be provided by the firsl API called 
by Ihe currant application. As an aside it will be noted 
. ... that the APIssuchas60and62areallpackaqed Each 

tor f^ZTZT 1 V tW3 w Sy T' d9SCnp - AP! may be ' h0U9ht °< as " rov ' dln 9 ^ to ea I 
on assoc ated with F,g. 3 proves information on the « of the different services provided bv the underlvinn n , 
usage context for the format 1 60. The format 160 is di 



differeni services provided by the underlying 0[ 
erating system software 93. In this context "packaging" 
refers to Ihe fact that all such APIs 60-62 own the global 
data and, more importantly, own the register preserva- 
tion table as well as Ihe space where the process infor- 
50 mation block is stored. In Ihis manner when one of the 
APIs 60-62 has read the current process information 
block, subsequent calls to different APIs in the same 
package would not have to read the block but could sim- 
ply access it which is the reason for step 104 in setting 
identified by the identification ss up global addressing because the block resides in the 
'-'-I correspondence, such that memory space shared by alt of the APIs in the package. 

In other words, step 1 04 sets up the addressing for such 
memory space retaining these blocks 



vided into a plurality of entries such as those indicated 
by reference numerals 152, 154, 156and158. An entry 
in format 160 represents space used lo store the con- 
tents of each and every register of the machine's main 
processor. A number of entries N is finite, as shown by 
boxes 156 and 156, and is assigned by the machine's 
operating system 98. N corresponds to the maximum 
number of execution threads allowed per application 
process. Entries 
number of threads 

the thread's identification number is used to locale its 
corresponding entry in format 160. 
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Stin referring to siep 106, every APf 60-62 will per- 
form this test 106 !o determine whether that bfock has 
been read. If it has not, a call to the operating system 
98 will be made requesting the operating system to read 
that block and load it into that memory space which be- 
longs to that particular API. Such information will remain 
in the block and is updated only by the operating system 
which is why the thread ID at any time wilt be current. 
The APIs 60-62 store not the block itself but rather the 
address of the block in that the block itseif belongs to 
the operating system 93, Consequently, what the APIs 
share is a memory location containing the address or in 
other words a pointer to the block updated only by the 
operating system. The only piece of information the 
APIs are concerned with in the block is the current 
threads ID. 

After a call is made to the operating system to obtain 
the address of that block at 110, so the APIs know where 
to obtain the thread ID, a robustness tesl 112 deter- 
mines whether the operating system performed the read ; 
successfully. Error detect ion at 112 sets up a return code 
at 116 so that an application 54 may be informed that 
the call from the application could not be completed suc- 
cessfully whereupon control is returned to the caller at 
142 due to system error. i 

If no errors were detected at 112, step 114 is per- 
formed wherein the address of the process information 
block is saved so the APIs can access the block without 
having to call the operating system every time. At step 
108, the information block is used to obtain the current s 
callers thread ID number. The thread ID number of the 
caller of the calling thread it is important to remember is 
updated by the operating system 98 as it splits the proc- 
essor between threads and processes .At step 118, this 
thread ID number is used to index into the state preser- 3 
vation table to access the area corresponding to thai 
thread ID. The state preservation table contains an entry 
which is an area where all register or process informa- 
tion is preserved. Every possible thread that an applica- 
tion p rogram can have has a pre-al located entry into the * 
slate preservation table implying the table is a static pre- 
aliocated table. Still at 118 using the thread ID number 
obtained at step 108 the table is indexed into and the 
entry is found corresponding to the calling thread's ID 
number. The partial processor state information saved « 
at step 100 pius the rest of the processor states that 
have not changed at this point are all saved in that entry 
to the state preservation lable. 

Next the algorithm proceeds to step 120 which is 
basically a step to remove the caller's return address se 
from the slack. The purpose for this step is to be able to 
make a call to the underlying function or API. This is 
important only in cases in which there is no need to ma- 
nipulate the parameters. There are some instances in 
which the only services performed by the APIs 60-62 is ss 
state preservation wherein the parameters might be 
identical, in other words, parameters might be adequate 
to the underlying function just as they are when passed 



by the application. In this case for efficiency reasons, all 
the generic APIs 60-62 need do is remove the return 
address from the slack at 1 20 where upon the algorithm 
may proceed to step 128. 
s At step 122 a check is made for presence of any 
string parameters. At this point it is worth noting that the 
algorithm as depicted in Fig. 5 is not an execution algo- 
rithm but rather an implementation algorithm whereby 
instances of the algorithm may be coded for each ge- 
0 neric API and a given API may not include all etemenls 
of the algorithm. For inslance step 122 is a step to de- 
termine whether to include code in the API to adjust 
string parameters. At coding time for the algorithm it 
would be known whether the interface has siring param- 
s eters ai test 122. li so, as indicated at step 124, code 
would be added to add nulls or zero .value bytes at the 
end of siring parameters whereby the end ot the string 
may be found by link parameters which are part of the 
generalization process. Since it is required that a null be 
' passedaspartofthestring, it is further required that the 
ieng;h or number of bytes in the string be passed. For 
a computerized version of the algorithm, steps 1 22- 1 24 
would have substituted therefor a step for adding zero 
value bytes to any siring length parameter without the 
; programmers decision at 122. 

At step 1 26 She algorithm would identify the param- 
eter frame (determined by the order and size of param- 
eters) to the generic API and compare its stack frame 
lo tha! of the underlying function, and if the same, will 
• proceed to step 128. If the underlying function does not 
have the same stack frame, at 130 code is provided 
which wilt build a slack frame for the underlying function 
as per its requirements using ihe slack frame which was 
passed to the generic APIs. Essentially then step 130 is 
a remapping o! the parameters. In either case, the algo- 
rithm proceeds to step 128 calling the underlying func- 
tion. Upon return from Ihe underlying function, Ihe algo- 
rithm proceeds at step 132 to save the lemporary return 
code from the underlying function on Ihe stack. Typically 
this return code is relurned in one of the registers 52, 
so step 132 amounts 10 sloring a register on the stack, 
that same register usually being modilied by the steps 
of Fig. 5. 

At step 134 global data is once again set up as in 
the case of step 104 because the registers may have 
been modilied by the underlying function. Step 136 in 
obtaining the calling thread ID number from Ihe process 
information is performed which is essentialiy a repetition 
of step 108. The algorithm proceeds to step 1 38 wherein 
the calling thread ID number obtained at step 136 is 
used to find again the processor state information pre- 
viously saved in step 118, i.e., that information is copied 
back lo the processor registers 52 thereby restoring the 
processor state lo the stale it whs in wher ihe function 
first was entered. At step 140 the caller's return address 
obtained at step 120 is now restored back on the stack 
48 whereupon the algorithm proceeds ai step 142 to re- 
turn control to the caller. 
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Claims 

1 . A method of interfacing a plurality oi application pro- 
grams (54) each written in a different computer lan- 
guage to a computer software system (93) such that 
said plurality of application programs may call func- 
tions provided by said computer software system, 
said method comprising generating a plurality of ge- 
neric application program interface systems (60, 
62) each responsive to program calls (94, 92) from 
said application programs for transforming param- 
eters for a program call received in a format deter- 
mined by the particular language of the application 
program into a form compatible with said computer 
software system and generating a call (94A, 92A) 
with said transformed parameters from one of said 
application program interface systems to a function 
provided by said computer software system in re- 
sponse to said program call; and 

executing said function provided by said com- 
puter software system in response to said call 
from said one ol said application program inter- 
face systems; 

said method being characterised in that said 
application program comprises two or more 
threads (56, 58), said program call being made 
by a thread, and the generic application pro- 
gram interface systems further performing the 
steps of: 

storing a processor state for (he thread making 
the program call to the generic application pro- 
gram interface system prior to generating said 
call with transformed parameters, said proces- 
sor state being stored in a memory location 
uniquely associated wilh that thread; and 
executing a return from said function call 
whereby said processor state is restored losaid 
processor slate stored in said memory and re- 
turn code information and control is returned to 
said applicalion program. 

2. The method of Claim 1 wherein said parameter 
transformation step includes generating a stack 
frame with parameters of one of said application « 
programs in a predetermined order. 

3. The method ol Claim 2 wherein said parameter 
transformation step further includes constructing a 
next stack frame with parameters of a next one of so 
said applications programs in said predetermined 
order. 

4. The method of Claim 3 wherein said predetermined 
order comprises a plurality of value parameters ss 
non-interleaved with a plurality of reference param- 



5. The method of Claim 4 further including the step of 
generating a state preservation table (160) com- 
prised of processor stale information entry groups 
each associated with a different thread of a corre- 
sponding one of said application programs. 

6. The method ol Claim 5 wherein said table is acces- 
sible to said plurality of generic application program 
interfaces. 

10 

7. The method of any of ciaims 1 lo 4 further including 
1he steps of, 

saving the state of said processor in a state 
'5 preservation table (160); 

setting up (102, 104) stack and global data ad- 
dressing; 

retrieving (108) a caller thread indentation; 
using (113) said thread identification as an in- 
so dex into said state preservation table to the 

memory location in the' table lor that thread; 
removing (120) a return address of said caller 
from said stack; 

storing (1 32) the return code from said function 
25 on said stack; 

setting up ( 1 34) global data addressing; 
returning (1 36) said caller thread identification, 
returning (1 38) said saved processor state from' 
sakjstate preservation table in response to said 
"> retrieved caller thread identification; 

storing (1 40) a return address of said. caller on 
said stack; and 

returning (142) control to said caller. 

ss 8. The method of Claim 7 further comprising 

detecting whether said executed function has 
a stack frame substantially identical to said 
stack frame; and 

storing parameters in said stack transformed in 
an order predetermined by said executed (unc- 
tion in response lo said detecting that said 
stack frame is not substantially identical. 

9. The method of Claim 8 further comprising 

delecting whether process information has 
been read; and 

calling an operating system of said computer 
system to read said process information in re- 
sponse to said detecting step indicating said 
process information has noi been read. 

10. The method of Claim 9 further comprising storing 
said read process information tor use in a next one 
of said calls. 
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11. A system for interfacing a plurality of application 
programs (54) each written in a different computer 
language to a computer software system (93) such 
that said plurality of application programs may call 
f unctions p rovided by said compute r software sys- s 
tern, said system comprising: 

a plurality of generic application program inter- 
face systems (60, 62) each responsive to pro- 
gram calis (94, 92} from said application pro- 10 
grams, including means for transforming pa- 
rameters for a program call received in a format 
determined by the particular language of the 
application program intoa form compatible with 
said computer software system, and means for is 
generating a call (94A. 92A) with said trans- 
formed parameters from one of said application 
program interface systems to a function provid- 
ed by said computer software system in re- 
sponse to said program cafl; so 
means for executing said function provided by 
said computer software system in response to 
said call from said one of said application pro- 
gram interface systems; 

said system being characterised in that said ap- zs 
plication program comprises two or more 
threads (56, 53), said program call being made 
by a thread, and the generic application pro- 
gram interface systems further comprise: 
means (200) for storing a processor state for so 
the thread making the program call to the ge- 
neric application program interface system pri - 
.or to generating said call with transformed pa- 
rameters, said processor state being stored in 
a memory location uniquely associated with & 
that thread; and 

means for executing a return from said function 
cal! whereby said processor state is restored to 
said processor state slored in said memory and 
return code information and control is returned 10 
to said application program. 

12. The system of Claim 11 further including means for 
generating a stack frame with parameters of one of 
said application programs in a predetermined order, is 

13. The system of Claim 12 including means lor con- 
structing a next stack frame with parameters of a 
next one of said application programs in said pre- 
determined order. so 

14. The system of Claim 1 3 further including means for 
generating a state preservation table (160) com- 
prised of processor state information entry groups 
each associated with a different thread of a corre- ss 
spending one of said application programs. 
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Pntenlenspruche 

1. Ein Verfahren fur eine Schnittstelle mehrerer An- 
wendungsprogramme (54), die jeweils in einer an- 
cieren Compulersprachs geschrieben sind, zu ei- 
nem Computer-Softwaresystem (93), mit dessen 
Hilfe die Anwendungsprogramme Funktionen auf- 
rulen konnen, die das Computer-Softwaresystem 
bereitsteilt, wobei das Verfahren beslehl aus dem 
Erzeugen mehrerer allgemeiner Schnitlstellensy- 
steme (60, 62) fur Anwendungsprogramme, die je- 
weils auf Programmauirute (94, 92) aus den An- 
wendungsprogrammen reagieren, zum Umformen 
von Parametem fur einen Programmaufruf, der in 
einem von der jeweiiigen Sprache des Anwen- 
dungsprogramms bestimmten Format empfangen 
wurde, in eine zu dem Computer-Soltwaresystem 
kompatible Form, und aus dem Erzeugen eines 
Aufrufs (94A, 92A) mit den umgeformten Parame- 
tem aus einem der Schnittsleflensysleme fOr An- 
wendungsprogramme an eine Funktion, die das 
Computer-Softwaresystem als Reaktion auf den 
Programmaufruf bereitsteilt; 

sowie aus dem Ausfuhren der von dem Com- 
puter-Softwaresystem bereitgestellten Functi- 
on als Reaktion auf den Aufruf aus einem der 
Schnrttstellensysleme fur Anwendungspro- 
gramme; 

wobei das Verfahren dadurch gekennzeichnet 
ist, dal3 das Anwendungsprogramm zwei oder 
mehr Threads (56, 58) umfsRt, wobei der Pro- 
grammaulruf von einem Thread durchgefuhrt 
wird und die allgemeinen. SehnitlstelSensyste- 
me fur Anwendungsprogramme ferner folgen- 
de Schritte ausfuhren: 

Speichern eines Prozessorzuslands fur den 
Thread, der den Programmaufruf an das allge- 
meine Schniltstellensystem lur Anwendungs- 
programme durchfuhrt, bevor or den Aufruf mit 
umgeformten Parametem erzeugt, wobei der 
Prozessorzustand an einer Speicherposition 
gespeichert wird, die diesem Thread eindeutig 
zugeordnet ist; und 

Ausfuhren einer Ruckkehr von dem Funkiions- 
aufruf, durch die der Prozessorzustand wieder 
in dBn Zustand zuruckversetzl wird, der im 
Speicher gespeichert ist, und die Ruckkehrco- 
deinformationen und die Steuerung an das An- 
wendungsprogramm zuruckgegeben werden. 

2. Das Verfahren nach Anspruch 1 , wobei der Schrilt 
der Parameterumwandlung das Erzeugen eines 
Stapelrahrnens mit Parametem eines der Anwen- 
dungsprogramme in einer vorbestimrmon Reihen- 



9 



17 



EP 0 371 941 B1 



18 



foige umfafBt. 

. Das Verfahren nach Anspruch 2, wobei der Schritt 
der Parameierumwandlung das Aufbauen eines 
nachsten Slapelrahmens mit Paramelern eines s 
nachsten Aunwendungsprogramms in der vorbe- 
stimmten Reiheniolge umfaGt. 

. Das Verfahren nach Anspruch 3, wobei die vorbe- 
stimmte Reihenfolge mehrere Werteparameter urn- io 
faflt, die mit mehreren Referenzparametem nicht 
verschachieft sind. 

Das Verfahren nach Anspruch 4, das ferner den 
Schritt des Erzeugens einer Zustandserhaltungsta- >s 
belfe (160) umfaSt, die aus Gruppen von Informa- 
tionert uber den Prozessorzustand bestehl, die je- 
weilszu einem anderen Thread eines entsprechen- 
den Anwendungsprogramms gehoren. 

Das Verfahren nach Anspruch 5, wobei die allge- 
meinen Schnittstellen fur Anwendungsprogramme 
aul die Tabelle zugreifen konnen. 

Das Verfahren nach einem der Anspruche 1 bis 4, a 
das ferner foigende Schritte umfaftt: 

Speichern des Zustands des Prozessors in ei- 
ner Zustandserhaltungstabelle (160), 
Einrichlen (102, 104) einerSiapel- und Global- 30 
datenadressierung; 

Abrufen (108) einer (dentifikation sines autiu- 
fenden Threads; 

Verwenden (118) der Thread-ldentifikation als 
Index auf die Zustandserhaltungstabelle lur die os 
Speicherposition in der Tabeile fur den beiref- 
fenden Thread; 

Enlfernen (120) einer Ruckkehradresse des 
aufrufenden Programms aus dem Stapel; 
Spefchern (132) des RQckkehrcodes aus der io 
Funktion in dem Stapel, 
Einrichten (1 34) der Globaldatenadressierung; 
Ruckkehr (136) der Thread-ldentifikation des 
aufrufanden Programms; 

Ruckkehr (1 38) des gespeicherten Prozessor- is 
zustands aus der Zustandserhaitungstabelle 
a!s Reaktion auf die abgerufene Thread-lden- 
tifikation des aufrufenden Programms; 
Speichern (140) einer Ruckkehradresse des 
aufrufenden Programms auf dem Stapel; und so 
RGckgabe (142) der Steuerung an das aufru- 
iende Programm. 

Das Verfahren nach Anspruch 7, das ferner foigen- 
de Schritle umiaBt: 55 

Feststelfen, ob die ausgefutirte Funktion einen 
Slapelrahmen hat, der mit diesem Stapeirah- 



men im wesenitichen identisch ist; und 

Speichern von Parametern in dem Stapel, um- 
geformt in einer durch dieausgefuhrte Funktion 
vorbestimmlen Reihenfoige, als Reaktion auf 
die Feststelfung, dal5 der Stapelrahmen nicht 
im wesenitichen identisch ist. 

9. Das Verfahren nach Anspruch 8, das ferner foigen- 
de Schritte umfaSt: 

Feststelfen, ob die Prozefrinformationen gefa- 
sen wurden; und 

Aufrufen eines Betriebssysiems des Compu- 
tersystems zum Lesen der Prozerainforrnatio- 
nen als Reaktion darauf , daS der Feststellungs- 
schrill anzeigt. daG die ProzeRinformationen 
nicht gelesen wurden. 

10. Das Verfahren nach Anspruch 9, das lemer das 
Speichern der gelesenen ProzefJinformationen zur 
Verwendung in einem nachsten Aufruf umfaGt. 

11. Ein System fur eine Schnitlstelle mehrerer Anwen- 
dungsprogramms (54), die jeweils in einer anderen 
Compuiersprache geschrieben sind, zu sinem 
Computer-Softwaresyslem (93), mit dessen Hilfe 
die Anwendungsprogramms Funktionen aufrufen 
konnen, die das Computer-Softwaresystem bereit- 
steflt, wobei das System umfaGt: 

mehrere aflgemeine. Schnittstellensysteme 
{60, 62) fur Anwendungsprogramme, die je- 
weils auf Programmauffufe (94, 92) aus den 
Anwendungsprogrammen reagieren, 
einschlieGlich eines Mitteis zum Umformen von 
Parametern fur einen Programrnaufruf, der in 
einem von der jeweiligBn Sprache des Anwen- 
dungsprogramms bestimmten Format empfan- 
gen wurde, in eine zu dem Computer-Soflware- 
system kompatible Form, und eines Mittels 
zum E rzeugen eines Aufrufs (94A, 92A) mit den 
umgeformten Parametern aus einem der 
Schnittstellensysteme fur Anwendungspro- 
gramme an eine Funktion, die das Computer- 
Softwaresystem als Reaktion auf den Pro- 
gramrnaufruf bereitstellt; und 
em Miltel zum Ausfuhren tier von dem Compu- 
ter-Softwaresystem berailgestallten Funktion 
als Reaktion au! den Aufrul aus einem der 
Schnittstellensysteme fur Anwendungspro- 
gramme; 

wobei das System dadurch gakonnzeichnei ist, 
daG das Anwendungsprogramm zwet Oder 
mehr Threads (56, 58) umfaGt, wobei der Pro- 
gramrnaufruf von einem Thread durchgefuhrt 
wird und die aligemeinen Schnittstellensyste- 
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me fur Anwendungs programme ferner folgen- 
des umfassen: 

ein Mittef (200) zum Speichern eines Prozes- 
sorzustands fur den Thread, der den Pro- 
grammaufrul an das allgemeine Schnittslellen- s 
system fur Anwendungsprogramme durch- 
fuhrt, bevor er den Aufruf mil umgeformten Pa- 
rametern erzeugt, wooei der Prozessorzustand 
an einer Speicherposition gespeicherl wind, die 
diesem Thread eindeutig zugeordnet ist; und >o 
ein Miltel zum Ausfuhren einer Ruckkehr von 
dem Funktionaaufruf, durch die der Prozessor- 
zustand wieder in den Zustand zuruckversetzt 
wird, der im Speicher gespeichert ist. und die 
ROckkefircodeinformationen und die Sleue- is 
rung an das Anwendungsprogramm zuruckge- 
geben werden. 

12. Das System nach Anspruch 1 1 , das femer ein Mittef 
zum Erzeugen eines Stapelrahmens mil Parame- ?o 
tern eines der Anwendungsprogramme in einer vor- 
bestimmten Reihenfolge umfaGt. 

13. Das System nach Anspruch 1 2, das ferner ein Mittel 
zum Aufbauen eines nachsten Stapelrahmens mil 2s 
Parametern eines nachsten Aunwendungspro- 
gramms in der vorbestimmten Reihenfolge umfaGt. 

1 4. Das System nach Anspruch 1 3, das ferner ein Mittef 
zum Erzeugen einer Zustandserhaltungstabelle so 
(160) umfafll, die aus Gruppen von Informaiionen 

uber den Prozessorzustand besteht, die (eweils zu 2. 
einem anderen Thread eines entsprechenden An- 
wendungsprogramms gehoren. 



Revendlcations 

3. 

1. Precede d'interfacage d'une pluralite de program- 
mes d'application (54), chacun ecrit dans un langa- to 
ge inlormatique different, avec un systems logiciel 
informalique (93) de telle sorte que tadile pluratite 
de programmes d'application peut appeler des 
fonctions procuress par ledit systeme logiciel inlor- 
matique, ledit precede comprenant la generation is 4, 
d'une pluralite de sysfemesd'interfaces generiques 
pour des programmes d'application (60. 62) repon- 
dant chacun aux appels de programme (94, 92) pro- 
venant desdits programmes d'application afin de 
transformer des parametres destines a un appel de so s. 
programme recus dans un format determine" par le 
langageparliculierdu programme d'application, en 
une forme compaiibie avec ledit systeme logiciel in- 
formalique et la generation d'un appef (94 A, 92A) 
avec lesdits parametres transformes provenant de ss 
I'un desdits systemes d'inleriaces pour program- 
mes d'application, vers une fonciion procure par 
ledit systeme logiciel informatique en reponse audit 6. 
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appei de programme, et 

I'sxScution de ladite fonciion fournie par ledit 
systeme logiciel informalique en reponse audi! 
appel provenant dudit un desdits systemes 
d'interfaces pour programmes d'application, 

ledit procede etant caracterise en ce que ledit 
programme d'application comprend deux ou 
plusieurs modules d'execution (56,58) ledit ap- 
pel de programme etant realise par un module 
d'execution et lesdits systemes d'interfaces ge- 
neriques pour programmes d'application exe- 
cutant en outre les etapes consistant a : 

m6moriser un etat de process eur pour le mo- 
dule d'execution realisant I'appel de program- 
me au systeme d'interiace generique pour pro- 
grammes d'application avant de generer ledit 
appel avec les parametres transformes, ledit 
etat de processeur etant enregistre dans un 
emplacement en memoire uniquementassocie 
a ce module d'execution, et 

executer un retour dudit appel de fonction d'oii 
il resufte que ledit etat de processeur est retabli 
, dans ledit etat de processeur memoriae dans 
ladite memoire et des informations de code de 
retour et la commande sont renvoyees audit 
programme d'application. 

Procede seton la revendication 1 dans lequel ladite 
etape de transformation de parametre comprend la 
generation d'un bloc de pileavec les parametres de 
I'un desdits programmes d'application dans un or- 
dre predetermine. 

Procede selon la revendication 2 dans lequel ladite 
etape de transformation de parametre comprend en 
outre la construction d'un bloc de pile suivant avec 
des parametres d'un programme suivant parmi les- 
dits programmes d'application, dans ledit ordra pre- 
determine. 

Procede selon la revendication 3 dans lequel ledit 
ordre predetermine comprend une pluralite de pa- 
rametres passes par valeurnon imbriques avec une 
pluralite de parametres passes reference. 

Precede selon Ja revendication 4 comprenant en 
outre I'etapa de generation d'une table de preser- 
vation d'etat (160) constitute do groupos d'entree 
d'informations d'etat de processeur, chacun asso- 
cie a. un module d'execution different d'un program- 
me correspondant parmi lesdits programmes d'ap- 
plication. 

Procede seton la revendication 5 dans lequel ladite 
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tabie est accessible a laciile plurality d'interfaces 
generiques pour programmes d'application. 

7. Procede seton I'une qu elco nque des revendicalions 
1 a A comprenant en outre les etapes consistant a, 

sauvegarder I'etal dudit processeur dans une 
tabie de preservation d'etat (160), 

initialiser (102, 104) I'adressage de pile et de 
donnees giobales, 

recuperer (108) una identification de module 
d'execution appelant, 

utiliser (118) ladite identification de moduie 
d'execution en tant qu'index dans ladite table 
de preservation d'etat vers I'emplacement me- 
moire dans la table destinee a ce module d'exe- 



supprimer (120) une adresse de retour dudit 
appelant de fadite pile, 

memoriser (132) le code de retour de ladite 
fonction sur ladite piie, 

initialiser (134) I'adressage de donnSes globa- 



retourner (137) ladite identification de module 
d'execution appelant, 

renvoyer (1 38) (edit etat de processeur sauve- 
garde a partir de ladite table de preservation 
d'etat en reponse a ladite idenlilicatron de mo- 
dule d'execution appelant recuperee, 

memoriser (140) une adresse de retour dudit 
, appelant sur ladite pile, el 



renvoyer (142) fa commande a 
Procede selon la revendication 7 comprenant en 

la detection du tail que ladite tonction executee 
comporte un bloc de piie pratiquement identi- 
que audit bloc de pile, et 

■ memoriser des paramelres dans ladite pile 
translormee dans u n ordre predetermine par la ■ 
dite lonction executee en reponse a ladite de- 
tection du fait que ledit bloc de pile n'asl pas 
subs tan lieliement idenltque. ; 

Procede selon la revendication S comprenant en 



I'appel au systeme d'exploitation dudfl sysieme 
inlormatique pour lire lesdites informations de 
traitement en reponse a ladite elape de detec- 
tion indiquant que lesdites informations de trai- 
tement n'ont pas etS lues. 

10. Procede selon la revendication 9 comprenant en 
outre la memorisation desdites informations de trai- 
tement lues pour une utilisation dans I'appei suivant 



11. Systeme destine a I'interfacage d'une pluralite de 
programmes duplication (54), chacun ecrit dans 
un langage iniormalique different, avec un systeme 
logiciel inlormatique (93) de telle sorte que ladite 
pluralite de programmes duplication peut appeler 
des fonctions procurees par ledit systeme logiciel 
informatique, ledit systeme comprenant ; 

une pluralite de systemes d'interfaces generi- 
ques pour programmes d'application (60, 62), 
repondant chacun aux appels de programme 
(94, 92) provenant desdits programmes d'ap- 
plication comprenant un moyen pour transfor- 
mer les paramfetres destines a un appel de pro- 
gramme recus dans un format determine par le ' 
langage -particulier du programme d'applica- 
tion. en une forme compatible avec ledit syste- 
me logicSe! informatique, et un moyen pour ge- 
n6rer un appel (94A, 92A) avec lesdits parame- 
tres transformes provenant de I'un desdits sys- 
temes d'interfaces pour programmes d'applica- 
tion vers une fonction procure par ledit syste- 
me logiciel informatique en reponse audit appel 
de programme, 

un moyen destine a executer ladite fonction 
procure par ledit systeme iogiciel informatique 
en reponse audit appel provenant dudit un des- 
dits systemes d'interfaces pour programmes 
d'application, 

[edit systeme etant caracterise en ce que ledit 
programme d'application comprend deux ou 
plusieurs modules d'execution (56, 58) ledit ap- 
pel de programme etant realise par un module 
. d'execulion et les systemes d'interfaces g£ne- 
riques pour programme d'application compre- 



un moyen (200) destine a memoriser un etai do 
processeur pour fe module d'execution rsali- 
sant I'appel de programme vers ie systeme d'in- 
ferface generique pour programme d'applica- 
tion ava/it de g&ierer ledit appal avec ies pa- 
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rametres transformes, ledit etat de processeur 
etant memorise dans un emplacement en mi- 
moire uniquement associe a ce module d'exe- 
cufion, eS 

5 

un moyen pour execute: un retour dudil appet 
de tonction d'ou il resulte que ledit etat de pro- 
cesseur est retabli dans ledit etat de proces- 
seur memorise dans ladite memoirs et des in- 
formations de code de retour et la commande J" 
sonl renvoyees audit programme d'application. 

12. Systeme selon la revendication 11 comprenant en 
outre un moyen destine a generer un bloc de pile 
avec des parametres de I'un desdits programmes ts 
d'application dans un ordre predetermine. 

13. Systeme selon la revendication 12 comprenant un 
moyen destine a construire un bloc de pile suivant, 
avec das parametres d'un programme suivant des- 20 
dits programmes d'application dans ledit ordre pre- 
determine. 

14. Systeme selon la revindication 13 comprenant en 
outre un moyen destine a generer une table de pre- 
servation d'etat (160) constitute de groupes d'en- 
treed'informations d'etat de processeur, chacun as- 
socie a un module d'execution different d'un pro- 
gramme correspondent dosdits programmes d'ap- 
plication. 
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